1. Field of the Invention
This invention relates generally to Java Digital Rights Management (DRM) systems, and particularly, to a dynamic rights management layer for enhancing the runtime behavior of a Java™ 2 Runtime Environment by enforcing users rights with respect to and preventing unauthorized uses of downloaded digital content.
2. Discussion of the Prior Art
With the advent of the Internet, the possibility to easily sell and rapidly distribute high-value digital contents has become a reality. There is a risk in this approach, though. Once downloaded to a client system, digital content can be misappropriated and illegally redistributed. While this problem has affected copyright material for centuries, the exposure with digital content is greater. A photocopy of a paper book is less valuable than the original, whereas a copy of an HTML book is identical to the original. Similarly, a copy of an analog audiotape has lower fidelity than the original; a copy of a digital audio file maintains its audio fidelity. Digital copies are perfect copies. With the prevalence of Internet access, it is possible for an unscrupulous entity to duplicate and distribute any number of unlicensed copies of an original. In fact, this can be done internationally, including from a server in a country with less restrictive intellectual property laws.
In the past few years, a number of Digital Rights Management (DRM) products have attempted to address the issue of licensing and controlling distribution of digital content. In general, all DRM systems allow the distribution of digital contents in an encrypted form. A set of rights is associated with the content, and only after acquiring the rights to access a protected piece of digital content will a user be allowed to decrypt it. Examples for such systems include IBM's EMMS, ContentGuard originally from Xerox, and the Metatrust system from Intertrust.
In a sophisticated DRM system, users are prevented from directly decrypting the contents. The decrypting key is hidden in the player. Therefore, they cannot decrypt the contents, save them, and distribute them in a decrypted form, unless they use a certified and tamper-resistant DRM software, which will allow such operations only if those users have acquired the rights to do so. However, the general approach adopted by the DRM systems commonly available on the market requires the use of a specific player, which can either be a totally new player (such as a new browser, media player, etc.) or a modified version of an existing player (such as a DRM-enabled version of an existing browser or media player). Users must install such a player in order to access any form of protected content that is downloaded on their machines. This approach may be secure enough to protect copyrighted material, but is highly intrusive, and lacks flexibility. In fact, the major problems associated with this solution are:
Platform Dependency
Tamper-resistant DRM software targeted to client systems will work only on the specific platform to which it has been written (typically, one of the Microsoft Windows™ flavors). However, nowadays, a substantial number of end users are starting to use PC platforms different from Windows™, such as Linux™ and Macintosh™. Moreover, even the Windows™ platforms present substantial differences that often require modification in the code. Therefore, the distribution across the Internet of high-value digital content will be successful only if a version of the DRM client code is written to each target platform.
In addition, even server machines can be DRM client systems. A Web server or Web application server machine may need to become DRM-enabled client to, say, acquire high-value digital contents and then disclose it only to specific users, or only under certain time- or price-related conditions. For server systems, the platform-dependency issue is even more important. In fact, for many servers the operating system belongs to the UNIX™ family.
In addition to this, many market analysts predict that DRM content distribution will be extremely successful as soon as small devices (such as cellular telephones and handheld computers) will become DRM-enabled. In other words, a version of the DRM client code should be provided for such devices too.
Application Dependency
When a DRM system is based on a particular application that is distributed to all the DRM clients, the major problem is that users will be allowed to use only that application if they want to access those contents. Other applications, even if they support that particular type of contents, will not work, because they will be unable to access or calculate the secret decrypting key, and decrypt the contents. This creates a limitation. Many users may want to use their preferred application (such as their favorite browser, with the plug-ins that they have installed on it, or their favorite media player, etc.). Existing applications may be more sophisticated than a DRM player, and end users may experience annoyance from the usage of an imposed application that they may not like.
Content Type Dependency
In the scenario just described, the set of content types that may be DRM-protected is limited by the number of content types supported by the DRM player. Let's assume, for example, that the DRM application is a browser. This could be a brand new browser, specific to DRM applications, or a modified version of an existing browser (such as Netscape™ Navigator™ or Microsoft™ Internet Explorer™). In such a situation, the set of contents that can be displayed by the DRM player is limited to HTML, GIF, JPEG, and a few other formats. If the digital publisher wanted to distribute MP3 music files in a protected fashion, a new DRM-enabled MP3 player should be written, or the browser should be enhanced to support the MP3 format, since common browsers do not support the MP3 format.
It is clear, then, that in order to be successful on the market, a DRM system should be flexible and minimally intrusive, and should not put any conditions on the type of the contents that need to be delivered, nor on the applications used to access such contents.
It would be further highly desirable to provide a DRM system for platform-independent computing system that implements a Java™ Virtual Machine (JVM) and provides a Java™ Runtime Environment (JRE).
Since its inception, Java™ has shown that it was designed for the net. Java™ brought about, for the first time on a large scale, the concept of dynamic loading of code from a source outside the system, i.e., “applets.” Though this is very powerful, and adds several features to the system using it, it is also a grave security threat. That is, there could be several risks associated with loading and running remote code. For instance, the remote code could steal memory, or CPU time; it could throw in a virus; it could read files on a local system and transmit them to another machine, etc. However, Java™ is not just for applets any more. Developers now use Java to build stand-alone, enterprise-class applications to enable disparate clients, such as workstations, PCs or Java™-based network computers to access legacy databases and share applications across the network.
It is immediately clear, then, why unlike other programming languages and systems, security mechanisms are an integral part of Java™. In fact, Java™ was designed to offer the following basic security measures: 1) Language design features—such as type safe conversions only, no pointer arithmetic, bounds checking on arrays—for providing strong memory protection; 2) a flexible sandbox mechanism for limiting what a Java™ program is permitted to do; and, 3) encryption and digital signatures which may be used by code providers to sign their Java™ application classes. In this way, the end user can ascertain who the owner of the code is and whether the class file was altered after having been signed by the provider's digital certificate. Java™ security additionally builds upon three fundamental components of the Java™ Runtime Environment (JRE): a ClassLoader that is responsible for locating and loading classes, ensuring that system-level components within the run-time environment are not replaced; a class file verifier that ensures proper formatting of downloaded code and verifies that the bytecode does not violate the type safety restrictions of the JVM, that internal stacks do not over/underflow, and that the byte code instructions will have correct typed parameters; and a SecurityManager that performs run-time access controls on attempts to perform file I/O, network I/O, create a new ClassLoader, manipulate Threads/ThreadGroups, start processes on the underlying operating system, terminate the JVM, load non-Java™ libraries (native code) into the JVM, perform certain types of windowing system operations and load certain types of classes into the JVM. For example, the Java™ applet sandbox, a function of the SecurityManager, severely constrains untrusted applets to a limited set of functions that are considered to be safe.
The focus of early versions of security in Java™ has been greatly on applets, and how to protect the client machine from malicious applets. For example, the first release of the Java™ Development Kit (JDK), called JDK V1.0, addressed the problem of protecting client machines from malicious applets by running all non-local code inside a sandbox. All local code (applications and applets) was by default trusted, and all non-local code, by default was untrusted. This initial limitation was partially solved in JDK V1.1, when signed remote applets were permitted access to several of the system resources that were off limits for those applets without signatures on them. The security scenario in the newer version of the JDK, called Java™ 2 SDK, extends the concept of signed code to local code as well. With the new security model, all code, whether loaded remotely or locally, signed or unsigned, will get access to system resources based on what is mentioned in one or more policy files. Now, two local codes no longer have the same access to system resources if one of them is considered trusted, and the other is not. The whole thing can be specified in the policy files as to what permission a user wishes to grant to code residing in which code source, or what permission a user wishes to grant to code signed by whom.
It would additionally be highly desirable to provide a platform-independent and application-independent DRM system obtained by enhancing the Java™ 2 security model that provides protection for digital contents once these have left a DRM server machine to reach a Java™ client.
It would further be highly desirable to provide an enhanced Java™ Runtime Environment (JRE) that is provided with a DRM that enables any Java™ player running on the JVM to become a DRM-enabled player in a manner that is transparent to the player/viewer application running on the host system.